How The Operation And Maintenance Team Uses Load Balancing To Alleviate The Taiwan Server Delay Problem Of Lol Mobile Games

1.

overview of the problem: current status and goals of delays in lol mobile games in taiwan

- player feedback: the average delay for local players in taiwan is usually between 120ms and 250ms, and can reach more than 300ms during peak periods.
-business goal: control average delay within 50ms, jitter <10ms, and packet loss rate <0.5%.
- affected links: public network to data center links, cross-border links, game session distribution and single point load pressure will all cause increased latency.
- operation and maintenance responsibilities: network diagnosis, load balancing strategy, server/host configuration, domain name resolution optimization and cdn/protection cooperation.
- key kpis: average rtt, packet loss rate, number of concurrent sessions, requests per second (qps), cpu/memory utilization of each instance.

2.

network diagnostics and baseline data collection

- commonly used tools: ping, mtr, traceroute, iperf3, tcpdump, prometheus + grafana monitoring.
- typical baseline example: measured from taipei to the current taiwan data center: average rtt=180ms, packet loss=2.4%, jitter=15ms.
- node detection: identify high-latency hops (as borders, international exits, cross-sea optical cables).
- bandwidth and concurrency: the measured peak concurrent number of players is 10k, corresponding to game handshake/heartbeat qps=6k per second.
- diagnostic conclusion: cross-border routing and sessions are concentrated on a single ap server, resulting in queue delays and packet loss.

3.

load balancing strategy selection: l4/l7, anycast and geodns combination

- l4 load balancing (such as haproxy tcp/nginx stream) for low-latency forwarding, supports session persistence and direct tcp proxy.
- l7 load balancing (such as nginx http) is suitable for game peripheral services (login, mall, patches, etc.).
- anycast is used to adsorb the nearest edge node to the player through bgp routing, reducing the number of cross-ocean hops.
- geodns is used to guide players to the nearest data center or backup node. the ttl is recommended to be set to 30s~60s.
- session persistence and consistent hashing: enable 5-minute stickiness or consistent hashing based on player id for live game sessions to avoid frequent reconnections.

4.

server and network configuration examples (including specific data demonstrations)

- deployment topology example: taipei, taiwan (main region) + singapore (backup), using local nodes to host real-time game sessions.
- single instance physical/cloud host configuration example: cpu intel xeon e5-2630 v4 8 cores, memory 16gb, network card 1gbps, os ubuntu 20.04.
- cluster size: 6 game servers in taipei cluster (each server supports 2k concurrent players), 2 hot standby servers in singapore.
- bandwidth budget: peak outbound bandwidth needs to be ≥600mbps (estimated based on 300kbps uplink and downlink peak per player).
- the following table shows the delay comparison before and after the actual test: the values ​​in the table are the actual measured sample average values ​​(unit: ms).

scene	average rtt before deployment	average rtt after deployment	packet loss rate
taipei->single node direct connection	180	48	0.3%
peak cross-sea flow (original)	240	65	0.6%

5.

specific implementation details and component recommendations

- load balancing software: haproxy (l4), nginx stream (l4/l7 mixed), configure health-check interval 5s, failure threshold 3 times.
- high availability: keepalived + vrrp realizes vip drift, and the active/standby switching time is <3s.
- session control: enable tcp keepalive, adjust socket backlog to 4096, net.core.somaxconn=4096.
- connection optimization: tuning kernel parameters (tcp_tw_reuse=1, tcp_fin_timeout=30, tcp_max_syn_backlog=4096).
- logs and alarms: prometheus collection delay, packet loss, number of connections; grafana panel and slack/pagerduty alarms.

6.

cooperation of cdn, domain name resolution and ddos protection

- cdn purpose: it is not used for real-time game traffic, but for static resources (patches, materials, login pages) to relieve the origin site and reduce latency.
- domain name strategy: the game entrance uses geodns or global traffic management (gtm), and the game api domain name ttl=30s for quick switching.
- ddos protection: use cloud vendors or professional protection (such as cloudflare spectrum, alibaba cloud anti-ddos), and the cleaning bandwidth is recommended to be ≥10gbps.
- protection practice: publish black hole policies and traffic mirroring to the cleaning center, whitelist legal traffic (heartbeat ip between game servers).
- fees and limits: example cost estimate: additional anycast export + 8 cloud hosts + 10gbps cleaning ≈ usd 8,000~12,000 per month (depending on traffic and manufacturer).

7.

real case: an operator’s optimization effect and experience summary in taiwan

- background: a mobile game manufacturer has 10k active players in taipei. the original architecture was concentrated in a single computer room, resulting in high latency and packet loss.
- measures taken: 6 new taipei edge clusters were added, haproxy was deployed for l4 load balancing, keepalived was enabled, geodns guided players to the nearest node, and cloudflare spectrum protection was added.
- result data: average rtt=180ms before deployment, stabilized at 45~60ms after deployment; packet loss rate dropped from 2.4% to 0.3% during peak period.
- experience points: localized deployment and anycast+geodns+l4 lb combination are the most critical. cdn is only used for non-real-time resources. ddos cleaning needs to be linked with isp.
- final suggestion: do a small-scale poc (2~3 nodes) first, collect monitoring data and then roll out capacity expansion, and keep dns ttl short for fast failover.